When should we start trimming the bloat in an operating system? Opinions vary widely. In most OSes, the developers don't worry too much about the growth in size with each new  version. Indeed, it's easy to justify having things in the kernel for speed, stability, or "efficiency." Of course, this will eventually lead to bloat and complexity. Featurism (especially in its creeping form) is the often ignored enemy of programmers.

Retro Native Forth goes against this trend by focusing on simplicity whenever possible. It is recognized that some areas (and many applications) will always be large and fairly comples, but the operating system does not need to be. When I started work on updating Retro I was still new to 32-bit assembly language (x86) and Forth. Retro looked promising to me because of its simplicity. I began to study the source and pare it down until I had a minimal Forth in just 500 lines. This was not practical though. There were bugs in it that couldn't be fixed without increasing its size, so I decided to combine the best features of Retro 4a and 4b. My initial updates were posted online in December 2001. Since then I've gone through a transitional generation of code (Retro 5) and am now hard at work on Retro's sixth generation.

With this generation, I have a self-imposed limit on complexity. I call it the 5k model. If it can't  be done in 5k, it's too bloated. This is a loose model. The "kernel" of Retro 6 is currently 2,798 bytes. There is plenty of room to grow. Over this is a VGA font (2k), and 2,021 bytes of Forth code. A graphical interface under development currently adds 1,535 bytes to the mix. Total size? 8,402 bytes. A fraction of  the size of even small operating systems such as DOS. Consider that 3,556  bytes of this is source code that is compiled when Retro boots. The final size is much less.

What do I expect from this model? By keeping the core system ("kernel" and initial Forth) to a maximum of 12k (5k kernel + 5k Forth + 2k Font), bloat has to be kept to a minimum. If you need a gui, it would take another 5k, maybe a little more for some extensions. It's not much considering the demands of Linux + XFree86 or Windows or MacOS.

When does this method fail to work? In complex applications. Many programs could be built over the minimal core provided by Retro 6, but some optional extensions will be much larger. We are hoping to bring a runtime C compiler to Retro in the future. I'd estimate the size to be 10-50k. Even this is not bad, considering how large most C compilers are. Voice recognition, plug and play, and a virtual file system are also examples of things that would probably be much larger than 5k. I intend to use the 5k model as a basis for the "kernel" and initial Forth environment. It is not forced, just recommended. My hope is that  this will provide us with one of the many guidelines needed to ensure a simple operating system.